# Protocol messaging plane structure

The messaging protocol is build on MLS, so it inherits part of the assumptions
of MLS.  MLS contains two conceptual layers, which I'm dubbing the "data plane"
and the "control plane", borrowing the names from the OSI networking model.  I'm
redefining these terms here to help understand how the terms we're using relate
to MLS concepts.

The data plane is the actual payload messages that are delivered within the
encryption sessions(s).  The format of these messages is unrestrained, and
determined from context.  These messages update encryption state, but are within
the ranges of epochs.

The control plane involves messaging involved in mediating which MLS keys are
recognized by a group and ultimately receive updates to the key structure.  The
primary primitives used to mediate this are the MLS "commits" and "epochs".

We also have an additional "policy" plane which sits outside of all the
essential e2ee cryptographic protocol messaging, managing the relationships
between related MLS groups within high level user-facing abstractions.  This
plane mediates the plaintext state to interact with user-facing identities and
group permission settings, so other parties in a group can safely identify when
they should trust a new device being added.  This also aids in homeservers being
able to implement the access control policies and reject messages upstream, on
users' behalfs.
